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Abstract 


This document aims to clarify terms and concepts presented in RFC 
3095. RFC 3095 defines a Proposed Standard framework with profiles 
for RObust Header Compression (ROHC). The standard introduces 
various concepts which might be difficult to understand and 
especially to relate correctly to the surrounding environments where 
header compression may be used. This document aims at clarifying 
these aspects of ROHC, discussing terms such as ROHC instances, ROHC 
channels, ROHC feedback, and ROHC contexts, and how these terms 
relate to other terms, like network elements and IP interfaces, 
commonly used, for example, when addressing MIB issues. 
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framework 
Various 


concepts are introduced within the standard that are not all very 
nsively defined and described, which can easily be an obstacle 
trying to understand the standard. This can especially be the 
case when one considers how the various parts of ROHC relate to the 
surrounding environments where header compression may be used. 
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The purpose of this document is to clarify these aspects of ROHC 

ugh examples and additional terminology, discussing terms such as 
instances, ROHC channels, ROHC feedback, and ROHC contexts. 

This especially means to clarify how these terms relate to other 

terms, such as network elements and IP interfaces, which are commonly 
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this document is to support and simplify the ROHC MIB development 
work. 
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The main part of this document, sections 3 to 8, focuses on 
clarifying the conceptual aspects, entity relationships, and 
terminology of ROHC [RFC-3095]. Section 9 explains some 
implementation implications that arise from these conceptual aspects. 


2. Terminology 
ROHC instance 


A logical entity that performs header compression or decompression 
according to one or several ROHC profiles can be referred to as a 
ROHC instance. A ROHC instance is either a ROHC compressor 
instance or a ROHC decompressor instance. See section 4. 


ROHC compressor instance 


A ROHC compressor instance is a logical entity that performs 
header compression according to one or several ROHC profiles. 
There is a one-to-one relation between a ROHC compressor instance 
and a ROHC channel, where the ROHC compressor is located at the 
input end of the ROHC channel. See section 4.1. 


ROHC decompressor instance 


A ROHC decompressor instance is a logical entity that performs 
header decompression according to one or several ROHC profiles. 
There is a one-to-one relation between a ROHC decompressor 
instance and a ROHC channel, where the ROHC decompressor is 
located at the output end of the ROHC channel. See section 4.2. 


Corresponding decompressor 


When talking about a compressor’s corresponding decompressor, this 
refers to the peer decompressor located at the other end of the 
ROHC channel to which the compressor sends compressed header 
packets, i.e., the decompressor that decompresses the headers 
compressed by the compressor. 


Corresponding compressor 


When talking about a decompressor’s corresponding compressor, this 
refers to the peer compressor located at the other end of the ROHC 
channel from which the decompressor receives compressed header 
packets, i.e., the compressor that compresses the headers the 
decompressor decompresses. 
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ROHC peers 


A ROHC compressor and its corresponding ROHC decompressor are 
referred to as ROHC peers. 


Link 


A communication path between two network entities is, in this 
document, generally referred to as a link. 


Bi-directional compression 


If there are means to send feedback information from a 
decompressor to its corresponding compressor, the compression 
performance can be improved. This way of operating, utilizing the 
feedback possibility for improved compression performance, is 
referred to as bi-directional compression. 


Unidirectional compression 


If there are no means to send feedback information from a 
decompressor to its corresponding compressor, the compression 
performance might not be as good as if feedback could be utilized. 
This way of operating, without making use of feedback for improved 
compression performance, is referred to as unidirectional 
compression. 


ROHC channel 


When a ROHC compressor has transformed original packets into ROHC 
packets with compressed headers, these ROHC packets are sent to 
the corresponding decompressor through a logical point-to-point 
connection dedicated to that traffic. Such a logical channel, 
which only has to carry data in this single direction from 
compressor to decompressor, is referred to as a ROHC channel. See 
section 5. 


ROHC feedback channel 


To allow bi-directional compression operation, a logical point- 
to-point connection must be provided for feedback data from the 
decompressor to its corresponding compressor. Such a logical 
channel, which only has to carry data in the single direction from 
decompressor to compressor, is referred to as a ROHC feedback 
channel. See section 6. 
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Co-located compressor/decompressor 


A minimal ROHC instance is only a compressor or a decompressor, 
communicating with a corresponding decompressor or compressor peer 
at the other end of a ROHC channel, thus handling packet streams 
sent in one direction over the link. However, in many cases, the 
link will carry packet streams in both directions, and it would 
then be desirable to also perform header compression in both 
directions. That would require both a ROHC compressor and a ROHC 
decompressor at each end of the link, each referred to as a co- 
located compressor/decompressor pair. 


Associated compressor/decompressor 


If there is a co-located ROHC compressor/decompressor pair at each 
end of a link, feedback messages can be transmitted from a ROHC 
decompressor to its corresponding compressor by creating a virtual 
ROHC feedback channel among the compressed header packets sent 
from the co-located ROHC compressor to the decompressor co-located 
with the compressor at the other end. When a co-located ROHC 
compressor/decompressor pair is connected for this purpose, they 
are said to be associated with each other. 


Interspersed feedback 


Feedback from a ROHC decompressor to a ROHC compressor can either 
be sent on a separate ROHC feedback channel dedicated to feedback 
packets, or sent among compressed header packets going in the 
opposite direction from a co-located (associated) compressor to a 
similarly co-located decompressor at the other end of the link. 

If feedback packets are transmitted in the latter way and sent as 
stand-alone packets, this is referred to as interspersed feedback. 
See section 6.2 for an example. 


Piggybacked feedback 


Feedback from a ROHC decompressor to a ROHC compressor can either 
be sent on a separate ROHC feedback channel dedicated to feedback 
packets, or sent among compressed header packets going in the 
opposite direction from a co-located (associated) compressor to a 
similarly co-located decompressor at the other end of the link. 
If feedback packets are transmitted in the latter way and sent 
encapsulated within compressed header packets going in the other 
direction, this is referred to as piggybacked feedback. See 
section 6.2 for an example. 
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Dedicated feedback channel 


A dedicated feedback channel is a logical layer two channel from a 
ROHC decompressor to a ROHC compressor, used only to transmit 
feedback packets. See sections 6.1 and 6.3 for examples. 


3.  ROHC External Terminology 


When considering aspects of ROHC that relate to the surrounding 
networking environment where header compression may be applied, 
unnecessary confusion is easily created because a common, well 
understood, and well defined, terminology is missing. One major goal 
with this document is to define the preferred terminology to use when 
discussing header compression network integration issues. 


3.1. Network Elements and IP Interfaces 


Header compression is applied over certain links, between two 
communicating entities in a network. Such entities may be referred 
to as "nodes", "network devices", or "network elements", all terms 
usually having the same meaning. However, practice within the area 
of network management favors using the term "network element", which 
is therefore consistently used throughout the rest of this document. 


A network element communicates through one or several network 
interfaces, which are often subject to network management, as defined 
by MIB specifications. In all IP internetworking, each such 
interface has its own IP identity, providing a common network 
interface abstraction, independent of the link technology hidden 
below the interface. Throughout the rest of this document, such 
interfaces will be referred to as "IP interfaces". 


Thus, to visualize the above terms, the top level hierarchy of a 
network element is as follows, with one or several IP interfaces: 


ee pee ne ere sae eee ee ee eee + 
| Network Element 

Toenn eenaa +--+------------—-- poerit + 
|? i ow | 

| Interface | | Interface | 

+-------------—- hl: Spee EEES + 


The next section builds on this top level hierarchy by looking at 
what is below an IP interface. 


Jonsson Informational [Page 6] 


RFC 3759 ROHC Terminology and Channel Mapping Examples April 2004 


3.2. Channels 


As mentioned in the previous section, an IP interface can be 
implemented on top of almost any link technology, although different 
link technologies have different characteristics, and provide 
communication by different means. However, all link technologies 
provide the common capability to send and/or receive data to/from the 
IP interface. A generic way of visualizing the common ability to 
communicate is to envision it as one or several logical communication 
channels provided by the link, where each channel can be either bi- 
directional or unidirectional. Such logical point-to-point 
connections will, throughout the rest of this document, be referred 
to as "channels", either bi-directional or unidirectional. Note that 
this definition of "channels" is less restrictive than the definition 
of "ROHC channels", as given in section 5. 


Extending the above network element hierarchy with the concept of 
channels would then lead to the following: 


$----------------- +--+ == = 5 = + 
| Network Element 
$--------------- +--4--------------- $------------------ + 
| IP o il IP | 
| Interface | | Interface | 
++ +-+ +-+ +----+ ++ +-+ +-+ +----+ 

[c] je] jel [ce] Ic] |c| 

|In] fa] fe] [In] In| [h] 

a a a a a a 

n n n n n n 

[na] Ina] fa] [a] fa] fa] 

lej je} [el [e| Jel e] 

[1] 


lz] [2] [1] 


Whether there is more than one channel, and whether the channel(s) 

is/are bi-directional or unidirectional (or a mix of both) is link 

technology dependent, as is the way in which channels are logically 
created. 


The following subsections, 3.3-3.6, give a number of different link 
examples, and relate these to the general descriptions above. 
Further, each section discusses how header compression might be 
applied in that particular case. The core questions for header 
compression are: 


- Are channels bi- or unidirectional? 


- Is the link point-to-point? If not, a lower layer addressing 
scheme is needed to create logical point-to-point channels. 
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Note that these subsections talk about header compression in general, 
while later sections will address the case of ROHC in more detail. 
Further, one should remember that in the later sections, the general 
channel definition is slightly enhanced for header compression by the 
definition of the ROHC channel (section 5) and the ROHC feedback 
channel (section 6), while here the basic channel concept is used, as 
defined above. 


3.3. A Unidirectional Point-to-Point Link Example 
The simplest possible link example one can derive from the general 


overview above is the case with one single unidirectional channel 
between two communicating network elements. 


4----------------- + 4----------------- + 
| Network Element | | Network Element | 
4----------------- + 4----------------- + 
| IP | | IP | 
| Interface | | Interface | 
+------ + 4+------ + +------ + 4+------ + 

| | HER 

4-------------------------------- + 
-> Unidirectional channel -> 
4---------------------------------------- + 


A typical example of a point-to-point link with one unidirectional 
channel like this is a satellite link. Since there is no return path 
present, only unidirectional header compression can be applied here. 


3.4. A Bi-directional Point-to-Point Link Example 


Taking the above example one step further, the natural extension 
would be an example with one single bi-directional channel between 
two communicating network elements. In this example, there are still 
only two endpoints and one single channel, but the channel is simply 
enhanced to allow bi-directional communication. 


+----------------- + +----------------- + 
| Network Element | | Network Element | 
+----------------- + +----------------- + 
| IP | | IP | 
| Interface | | Interface | 
+------ +  +------ + +------ +  +------ + 

| | | | 

| +-------------------------------- + | 

| <-> Bi-directional channel <-> | 

+---------------------------------------- + 
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A typical example of a point-to-point link with such a bi-directional 
channel is a PPP modem connection over a regular telephone line. 
Header compression can easily be applied here as well, as is usually 
done over e.g., PPP, and the compression scheme can make use of the 
return path to improve compression performance. 


3.5. A Bi-directional Multipoint Link Example 


Leaving the simple point-to-point link examples, this section 
addresses the case of a bi-directional link connecting more than two 
communicating network elements. To simplify the example, the case 
with three endpoints is considered. 


+----------------- + +----------------- + +----------------- + 
| Network Element | | Network Element | | Network Element | 
+----------------- + +----------------- + +----------------- + 
| IP | | IP | | IP | 
| Interface | | Interface | | Interface 
+----—- + +------ + +------ + +------ + +------ + +------ + 
| | | | | 
| | | | | | 
+----------------- + +----------------- + 
<-> Bi-directional "Shared channel" <-> 
+--------------------------- - + 


A typical example of a multipoint link with such a bi-directional 
"shared channel" is an Ethernet. Since the channel is shared, 
applying header compression would require a lower layer addressing 
scheme to provide logical point-to-point channels, according to the 
definition of "channels". 


As an aside, it should be noted that a case of unidirectional 
multipoint links is basically the same as a number of unidirectional 
point-to-point links. In such a case, each receiver only sees one 
single sender, and the sender’s behavior is independent of the number 
of receivers and is unaffected by their behavior. 


3.6. A Multi-Channel Point-to-Point Link Example 


This final example addresses a scenario which is expected to be 
typical in many environments where ROHC will be applied. The key 
point of the example is the multi-channel property, which is common 
in, for example, cellular environments. Data through the same IP 
interface might here be transmitted on different channels, depending 
on its characteristics. In the following example, there are three 
channels present, one bi-directional, and one unidirectional in each 
direction, but the channel configuration could of course be 
arbitrary. 
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IP | 
Interface | 
---+ +---+ +-+ 


+ 
| | 
| 
| 


IP | 
| 


| | | 
| | | | 
| ee ee TE 
| | | 
| o 
| | | 
| | | 
| | 


-> Unidirectional channel -> 


As mentioned above, a typical example of a multi-channel link is a 
cellular wireless link. In this example, header compression would be 
applicable on a per-channel basis, for each channel operating either 
in a bi-directional or unidirectional manner, depending on the 
channel properties. 


4. ROHC Instances 


For various purposes, such as network management on an IP interface 
implementing ROHC, it is necessary to identify the various ROHC 
entities that might be present on an interface. Such a minimal ROHC 
entity will, from now on, be referred to as a "ROHC instance". A 
ROHC instance can be one of two different types, either a "ROHC 
compressor" or a "ROHC decompressor" instance, and an IP interface 
can have N ROHC compressors and M ROHC decompressors, where N and M 
are arbitrary numbers. It should be noted that although a compressor 
is often co-located with a decompressor, a ROHC instance can never 
include both a compressor and a decompressor; where both are present, 
they will be referred to as two ROHC instances. 


The following two subsections describe the two kinds of ROHC 
instances and their external interfaces, while sections 5 and 6 
address how communication over these interfaces is realized through 
"ROHC channels" and "ROHC feedback channels". Section 7 builds on 
top of the instance, channel and feedback channel concepts, and 
clarifies how ROHC contexts map to this. 
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It should be noted that all figures in sections 4-6 have been rotated 
90 degrees to simplify drawing, i.e., they do not show a "stack 


view". 


4.1. ROHC Compressors 


A ROHC compressor instance supports header compression according to 
one or several ROHC profiles. Apart from potential configuration or 


control interfaces, 


a compressor instance receives and sends data 


through 3 inputs and 1 output, as illustrated by the figure below: 


Uncompressed Input (UI): 


Compressed Output (CO): 


Feedback Input 
[optional] 


Piggyback Input 
[optional] 


Jonsson 


(FI): 


(PI): 


| 
| ROHC 
| 
| 


Uncompressed packets are delivered from 
higher layers to the compressor through 
the UI. 


Compressed packets are sent from the 
compressor through the CO, which is 
always connected to the input end of a 
ROHC channel (see section 5). 


Feedback from the corresponding 
decompressor is received by the 
compressor through the FI, which (if 
present) is connected to the output end 
of a ROHC feedback channel of some kind 
(see section 6). When there are no 
means to transmit feedback from 
decompressor to compressor, FI is not 
used, and bi-directional compression 
will not be possible. 


If the compressor is associated with a 
co-located decompressor, for which the 
compressor delivers feedback to the 

other end of the link, feedback data 

for piggybacking is delivered to the 
compressor through the PI. If this input 
is used, it is connected to the FO of the 
co-located decompressor (see section 
4.2). 
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4.2. ROHC Decompressors 


A ROHC decompressor instance supports header decompression according 
to one or several ROHC profiles. Apart from potential configuration 
or control interfaces, a decompressor instance receives and sends 
data through 1 input and 3 outputs, as illustrated by the figure 


below: 

+-------------- + 

-> CI -> | | -> DO -> 
| ROHC | 
| Decompressor | 

<- FO <- | | -> PO -> 
+-------------- + 

Compressed Input (CI): Compressed packets are received by the 


decompressor through the CI, which is 
always connected to the output end of a 
ROHC channel (see section 5). 


Decompressed Output (DO): Decompressed packets are delivered from 
the decompressor to higher layers 
through the DO. 


Feedback Output (FO): Feedback to the corresponding compressor 
[optional] is sent from the compressor through the 

FO, which (if present) is connected to 
the input end of a ROHC feedback channel 
of some kind (see section 6). When 
there are no means to transmit feedback 
from decompressor to compressor, FO is 
not used, and bi-directional compression 
will not be possible. 


Piggyback Output (PO): If the decompressor is associated with 

[optional] a co-located compressor to which the 
decompressor delivers feedback it 
receives piggybacked from the other end 
of the link, the received feedback data 
is delivered from the decompressor 
through the PO. If this output is used, 
it is connected to the FI of the co- 
located compressor (see section 4.1). 
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3% 


ROHC Channels 


In section 3, a general concept of channels was introduced. 
According to that definition, a channel is basically a logical 
point-to-point connection between the IP interfaces of two 
communicating network elements. By that definition, a channel 
represents the kind of logical connection needed to make header 
compression generally applicable, and then the channel properties 
control whether compression can operate in a unidirectional or bi- 
directional manner. 


The channel concept thus facilitates general header compression 
discussions, but since it groups unidirectional and bi-directional 
connections together, it does not provide the means for describing 
details of how ROHC logically works. Therefore, for the case of 
ROHC, the channel concept is enhanced and a more restricted concept 
of "ROHC channels" is defined. 


A ROHC channel has the same properties as a channel, with the 
difference that a ROHC channel is always unidirectional. A ROHC 
channel therefore has one single input endpoint, connected to the CO 
of one single ROHC compressor instance, and one single output 
endpoint, connected to the CI of one single ROHC decompressor 
instance. A ROHC channel must thus in this way be logically 
dedicated to one ROHC compressor and one ROHC decompressor, hereafter 
referred to as ROHC peers, creating a one-to-one mapping between a 
ROHC channel and two ROHC compressor/decompressor peers. 


+-------------- + --->-->-->-->--- +—-------------- + 
| | -> CO -> ROHC Channel -> CI -> | | 
| ROHC | --->-->-->-->--—- | ROHC | 
| Compressor | | Decompressor | 
| | | | 
toss + toss 5 5 + 


In many cases the lower layer channel is by nature bi-directional, 
but for ROHC communication over that channel, a ROHC channel would 
only represent one communication direction of that channel. For bi- 
directional channels, a common case would be to logically allocate 
one ROHC channel in each direction, allowing ROHC compression to be 
performed in both directions. The reason for defining ROHC channels 
as unidirectional is basically to separate and generalize the concept 
of feedback, as described and exemplified in section 6. 
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6. 


6. 


ROHC Feedback Channels 


Since ROHC can be implemented over various kinds of links, 
unidirectional or bi-directional one-channel links, as well as 
multi-channel links, the logical transmission of feedback from 
decompressor to compressor has been separated out from the transport 
of actual ROHC packets through the definition of ROHC channels as 
always being unidirectional from compressor to decompressor. This 
means that an additional channel concept must be defined for 
feedback, which is what will hereafter be referred to as "ROHC 
feedback channels". 


In the same way as a ROHC channel is a logically dedicated 
unidirectional channel from a ROHC compressor to its corresponding 
ROHC peer decompressor, a ROHC feedback channel is a logically 
dedicated unidirectional channel from a ROHC decompressor to its 
corresponding ROHC peer compressor. A ROHC feedback channel thus has 
one single input endpoint, connected to the FO of one single ROHC 
decompressor instance, and one single output endpoint, connected to 
the FI of one single ROHC compressor instance. 


+-------------- + +-------------- + 
| | | | 
| ROHC | | ROHC | 
| Compressor | —-<--<--<--<--<-- | Decompressor | 
| | <- FI <- ROHC FB Channel <- FO <- | | 
4+-------------- + —-<--<--<--<--<-- 4+-------------- + 


The reason for making this simplification and logically separating 
ROHC channels from ROHC feedback channels is generality for handling 
of feedback. ROHC has been designed with the assumption of logical 
separation, which creates flexibility in realizing feedback 
transport, as discussed in [RFC-3095, section 5.2.1]. There are no 
restrictions on how to implement a ROHC feedback channel, other than 
that it must be made available and be logically dedicated to the ROHC 
peers if bi-directional compression operation is to be allowed. 


The following subsections provide some, not at all exhaustive, 
examples of how a ROHC feedback channel might possibly be realized. 


1. Single-Channel Dedicated ROHC Feedback Channel Example 


This section illustrates a one-way compression example where one bi- 
directional channel has been configured to represent a ROHC channel 

in one direction and a dedicated ROHC feedback channel in the other 

direction. 
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Bi-directional channel 


+-------------- + a 4+-------------- + 
--> |UI co| --> : ROHC Channel : --> [cI DO| --> 
| ROHC | : -->-->-->-->—- : | ROHC 
| Compressor | : | Decompressor | 
| : --<--<--<--<-- : 
o [PI FI| <-- : FB Channel : <-- |FO PO| o 
+-------------- + : --<--<--<--<—- : $-------------- + 


In this example, feedback is sent on its own dedicated channel, as 
discussed in e.g., feedback realization example 1-3 of ROHC [RFC- 


3095, page 44]. This means that the piggybacking/interspersing 
mechanism of ROHC is not used, and the PI/PO connections are thus 
left open (marked with a "o"). To facilitate communication with ROHC 


compression in a two-way manner using this approach, an identical 
configuration must be provided for the other direction, i.e., making 
use of four logical unidirectional channels. 


6.2. Piggybacked/Interspersed ROHC Feedback Channel Example 


This section illustrates how a bi-directional channel has been 
configured to represent one ROHC channel in each direction, while 
still allowing feedback to be transmitted through ROHC piggybacking 
and interspersing. 


Bi-directional channel 


5 aaa eet RE + Hse Sa eace Seca sa ae atl a rd + 
--> |UI co| --> : ROHC Channel A : --> [CI DO| --> 
| ROHC | : -->-->-->-->—- : | ROHC 
| Compressor | ; : | Decompressor | 
A A 
+> PI ETN KEF F= | PO FOJ Sat 
| $-------------- + | | +-------------- + | 
| | | | 
| | | | 
| +-------------- + | | +-------------- + | 
+-- |FO PO| --+ +-> |FI PI| <-+ 
ROHC ROHC 
| Decompressor | ; : | Compressor | 
| B | : --<--<--<--<-- : | B | 
<-- |DO CI] <-- : ROHC Channel B : <-- |CO uI| <-- 
Por Enea + 2 --<--<--<--<--. ¢ t-------------- + 
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In this example, feedback is transmitted piggybacked or interspersed 
among compressed header packets in the ROHC channels, as discussed in 
e.g., feedback realization example 4-6 of ROHC [RFC-3095, page 44]. 
Feedback from decompressor A to compressor A is here sent through 
FO(A)->PI(B), piggybacked on a compressed packet over ROHC channel B, 
and delivered to compressor A through PO(B)->FI(A). A logical ROHC 
feedback channel is thus provided from the PI input at compressor B 
to the PO output at decompressor B. It should be noted that in this 
picture, PO and FO at the decompressors have been swapped to simplify 
drawing. 


6.3. Dual-Channel Dedicated ROHC Feedback Channel Example 
This section illustrates how two bi-directional channels have been 
configured to represent two ROHC channels and two dedicated ROHC 


feedback channels, respectively. 


Bi-directional channel 


+-------------- + : -->-->-->-->—- : +-------------- + 
->| UI co| --> : ROHC Channel A : --> |CI DO|-> 
ROHC to -->-->-->-->-- ROHC 
| Compressor : : Decompressor 
A | A 

| | | | 
+-> |FI PI| o : 0 |PO FO| --+ 
| $-------------- + : --<--<--<--<—- : +-------------- + 

+- : ROHC Channel B :<-+ 
| | oo: --<--<--<--<-- : | | 
| 9 +-------------- el, oo Cet hades a ate Labs ac | +-------------- + | 
| <-|DO CI|<-+ +- |co ur|<- | 
| | ROHC | | ROHC | | 
| | Decompressor | Bi-directional channel | Compressor | | 
B- | (PESO Cae ere A ere ENE B 

| paan: | 
| o|PO FO| --> : FB Channel B : --> |FI PIlo | 
| +-------------- + : -->-->-->-—->—- : +-------------- + 
| | 
| | 


: --<--<--<--<-- ; 
tis S See ass a tea SSeS Z FB Channel Av 3) Kanno AAE e F 
E a a a ;: 


In this example, feedback is, in both directions, sent on its own 
dedicated channel, as discussed in e.g., feedback realization example 


1-3 of ROHC [RFC-3095, page 44]. With this configuration, the 
piggybacking/interspersing mechanism of ROHC is not used, and the 
PI/PO connections are thus left open (marked with a "o"). It should 
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be noted that in this picture FI/PI and PO/FO at the A-instances have 
been swapped to simplify drawing, while the B-instances have been 
horizontally mirrored. 


7. ROHC Contexts 


In previous sections, it has been clarified that one network element 
may have multiple IP interfaces, one IP interface may have multiple 
ROHC instances running (not necessarily both compressors and 
decompressors), and for each ROHC instance, there is exactly one ROHC 
channel and optionally one ROHC feedback channel. How ROHC channels 
and ROHC feedback channels are realized will differ from case to 
case, depending on the actual layer two technology used. 


Each compressor/decompressor can further compress/decompress an 
arbitrary (but limited) number of concurrent packet streams sent over 
the ROHC channel connected to that compressor/decompressor. Each 
packet stream relates to one particular context in the 
compressor/decompressor. When sent over the ROHC channel, compressed 
packets are labeled with a context identifier (CID), indicating to 
which context the compressed packet corresponds. There is thus a 
one-to-one mapping between the number of contexts that can be present 
in a compressor/decompressor and the context identifier (CID) space 
used in compressed packets over that ROHC channel. This is 
illustrated by the following figure: 


a O Se ss Se ease ee ase E + 
| IP Interface 
R E E E E a E E AF EER t-------- + 
| ROHC | | ROHC | | ROHC | 
| Compressor | | Compressor | | Decompressor | 
| Context 0...N | | Context 0...M | | Context 0...K | 
to-4-7- 7-7-7 +--+ to-4-5- 5-7-7 +--+ to-4-5 55-77 +--+ 
CID CID 3- iD- | 
0...N | 0...M | ze ‘Deca || 
: v : v v 
ROHC ROHC ROHC ROHC ROHC ROHC 
Feedback Channel Feedback Channel Feedback Channel 
Channel Channel Channel 


It should be noted that each ROHC instance at an IP interface 
therefore has its own context and CID space, and it must be ensured 
that the CID size of the corresponding decompressor at the other end 
of the ROHC channel is not smaller than the CID space of the 
compressor. 
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8. 


Summary 


This document has introduced and defined a number of concepts and 
terms for use in ROHC network integration, and explained how the 
various pieces relate to each other. In the following bullet list, 
the most important relationship conclusions are repeated: 


- A network element may have one or several IP interfaces. 


- Each IP interface is connected to one or several logical layer two 
channels. 


- Each IP interface may have one or several ROHC instances, either 
compressors, decompressors, or an arbitrary mix of both. 


- For each ROHC instance, there is exactly one ROHC channel, and 
optionally exactly one ROHC feedback channel. 


- How ROHC channels and ROHC feedback channels are realized through 
the available logical layer two channels will vary, and there is 
therefore no general relation between ROHC instances and logical 
layer two channels. ROHC instances map only to ROHC channels and 
ROHC feedback channels. 


- Each compressor owns its own context identifier (CID) space, which 
is the multiplexing mechanism it uses when sending compressed 
header packets to its corresponding decompressor. That CID space 
thus defines how many compressed packet streams can be 
concurrently sent over the ROHC channel allocated to the 
compressor/decompressor peers. 


Implementation Implications 


This section will address how the conceptual aspects discussed above 
affect implementations of ROHC. 


ROHC is defined as a general header compression framework on top of 
which compression profiles can be defined for each specific set of 
headers to compress. Although the framework holds a number of 
important mechanisms, the separation between framework and profiles 
is mainly a separation from a standardization point of view, to 
indicate what must be common to all profiles, what must be defined by 
all profiles, and what are profile-specific details. To implement 
the framework as a separate module is thus not an obvious choice, 
especially if one wants to use profile implementations from different 
vendors. However, optimized implementations will probably separate 
the common parts and implement those in a ROHC framework module, and 
add profile modules to that. 
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10. 


Tig 


LD. 


13. 


A ROHC instance might thus consist of various pieces of 
implementation modules, profiles, and potentially also a common ROHC 
module, possibly from different vendors. If vendor and 
implementation version information is made available for network 
management purposes, this should thus be done on a per-profile basis, 
and potentially also for the instance as a whole. 


Security Considerations 


The clear understanding of ROHC channels and their relations to IP 
interfaces and the physical medium, plays a critical role in ensuring 
secure usage of ROHC. This document is therefore a valuable adjunct 
to the Security Considerations found in RFC 3095 and other ROHC 
specifications. However, as it just reviews information and 
definitions, it does not add new security issues to the ROHC protocol 
specifications. 
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